<!DOCTYPE html>
<html lang="zh-CN">
<head>
      <script src="https://csdnimg.cn/public/common/libs/jquery/jquery-1.9.1.min.js" type="text/javascript"></script>
    <script src="https://csdnimg.cn/rabbit/exposure-click/main-1.0.6.js"></script>
</head>
<body class="nodata " > 
    <link rel="stylesheet" href="https://csdnimg.cn/public/common/toolbar/content_toolbar_css/content_toolbar.css">
    <link rel="stylesheet" href="https://csdnimg.cn/release/phoenix/template/css/chart-3456820cac.css" />
</div>	    <main>
        <div class="blog-content-box">

  <article class="baidu_pl">
    <div id="article_content" class="article_content clearfix csdn-tracking-statistics" data-pid="blog" data-mod=popu_307 data-dsm="post">
					 <link rel="stylesheet" href="https://csdnimg.cn/release/phoenix/template/css/ck_htmledit_views-cd6c485e8b.css" />
                              <link rel="stylesheet" href="https://csdnimg.cn/release/phoenix/template/css/ck_htmledit_views-cd6c485e8b.css" />
          <div class="htmledit_views" id="content_views">
            <table align="left" border="1" cellpadding="1" cellspacing="1"><caption>kafka配置参数详解</caption>
	<thead><tr><th scope="col" style="width:259px;">参数名称</th>
			<th scope="col" style="width:540px;">参数解释</th>
		</tr></thead><tbody><tr><td style="width:259px;">acks</td>
			<td style="width:540px;">
			<p>acks指定了必须有多少个分区副本接收到了消息，生产者才会认为消息是发送成功的。</p>

			<ol><li>acks=0，生产者成功写入消息之前不会等待来自任何服务器的响应，这种配置，提高吞吐量，但是消息存在丢失风险。</li>
				<li>acks=1，只要集群的leader（master）收到了消息，生产者将会受到发送成功的一个响应，如果消息无撞到达首领节点（比如首领节点崩愤，新的首领还没有被选举出来），生产者会收到一个错误响应，为了避免数据丢失，生产者会重发消息。不过，如果一个没有收到消息的节点成为新首领，消息还是会丢失。这个时候的吞吐量取决于使用的是<br />
				同步发送还是异步发送。如果让发送客户端等待服务器的响应（通过调用Futu re 对象的get（）方法，显然会增加延迟（在网络上传输一个来回的延迟）。如果客户端使用回调，延迟问题就可以得到缓解，不过吞吐量还是会受发送中消息数量的限制（比如，生产者在收到服务器响应之前可以发送多少个消息）。</li>
				<li>acks=all，所有参与复制的节点全部收到消息的时候，生产者才会收到来自服务器的一个响应，这种模式最安全，但是吞吐量受限制，它可以保证不止一个服务器收到消息，就算某台服务器奔溃，那么整个集群还是会正产运转。</li>
			</ol></td>
		</tr><tr><td style="width:259px;">buffer.memory</td>
			<td style="width:540px;">
			<p>该参数用来设置生产者内存缓冲区的大小，缓冲生产者发往服务器的消息，如果生产者发送速率大于服务器接受速率，那么会导致生产者内存空间不足，此时send方法要么阻塞，要么爬出异常，具体行为依赖于，block.on.buffer.full参数，0.9.0.0版本中被替换成了max.block.ms用来设置抛出异常之前可以阻塞一段时间。</p>
			</td>
		</tr><tr><td style="width:259px;">compression.type</td>
			<td style="width:540px;">消息压缩算法，snappy消耗较低的CPU并且有较为理想的压缩比和压缩性能，如果对于性能和网络带宽，这是一种比较理想的算法（Google发明的算法，Google是真牛逼），gzip算法耗费CPU资源比较多，但是提高了很高的压缩比，如果对于网络带宽有着很高的要求，那么这种算法比较适合。<strong><span style="color:#f33b45;">使用压缩可以降低网络传输开销和存储开销，这也往往是向kafka发送消息的瓶颈所在。</span></strong></td>
		</tr><tr><td style="width:259px;">retries</td>
			<td style="width:540px;">生产者从服务器收到的错误消息有可能是临时的，当生产者收到服务器发来的错误消息，会启动重试机制，当充实了n（设置的值）次，还是收到错误消息，那么将会返回错误。生产者会在每次重试之间间隔100ms，不过可以通过<span style="color:#f33b45;"><strong>retry.backoff.ms</strong></span>改变这个间隔。</td>
		</tr><tr><td style="width:259px;">batch.size</td>
			<td style="width:540px;">当多个消息发往 同一个分区，生产者会将他们放进同一个批次，该参数指定了一个批次可以使用的内存大小，按照字节数进行计算，不是消息个数，当批次被填满，批次里面所有得消息将会被发送，半满的批次，甚至只包含一个消息也可能会被发送，所以即使把批次设置的很大，也不会造成延迟，只是占用的内存打了一些而已。但是设置的太小，那么生产者将会频繁的发送小，增加一些额外的开销。</td>
		</tr><tr><td style="width:259px;">linger.ms</td>
			<td style="width:540px;">该参数指定了生产者在发送批次之前等待更多消息加入批次的时间。KafkaPr oduce 「会在<br />
			批次填满或linger.ms达到上限时把批次发送出去。默认情况下，只要有可用的线程， 生<br />
			产者就会把消息发送出去，就算批次里只有一个消息。把linger.ms设置成比0 大的数，<br />
			让生产者在发送批次之前等待一会儿，使更多的消息加入到这个批次。虽然这样会增加延<br />
			迟，但也会提升吞吐量（因为一次性发送更多的消息，每个消息的开销就变小了）</td>
		</tr><tr><td style="width:259px;">client.id</td>
			<td style="width:540px;">服务器会根据该参数值来识别消息的来源，还可以用在日志配置以及配额指标里</td>
		</tr><tr><td style="width:259px;">max.in.flight.requests.per.connection</td>
			<td style="width:540px;">指定了生产者收到服务器响应之前可以发送多少个消息。它的值越高，将会消耗更多的内存，不过也会提升吞吐量。<span style="color:#f33b45;"><strong>设置为1，可以保证消息是按照发送的顺序写入服务器。即使发生了重试。</strong></span></td>
		</tr><tr><td style="width:259px;">timeout.ms</td>
			<td style="width:540px;">指定了broker等待同步副本返回消息的时间，如果指定时间同步副本没有返回消息，那么将会返回错误。</td>
		</tr><tr><td style="width:259px;">requests.timeout.ms</td>
			<td style="width:540px;">生产者发送数据时等待服务器返回响应的时间</td>
		</tr><tr><td style="width:259px;">metadata.fetch.timeout.ms</td>
			<td style="width:540px;">生产者在获取元数据（例如分区首领是谁？）时等待服务器的响应时间，如果响应时间接收不到消息，那么要么重试要么返回一个错误（抛出异常或者执行回调）</td>
		</tr><tr><td style="width:259px;">max.block.ms</td>
			<td style="width:540px;">该参数指定了在调用send()方法或使用partitionFor() 方法获取元数据时生产者的阻塞<br />
			时间。当生产者的发送缓冲区已满，或者没有可用的元数据时，这些方法就会阻塞。在阻<br />
			塞时间达到max.block.ms 时，生产者会抛出超时异常。</td>
		</tr><tr><td style="width:259px;">max.request.size</td>
			<td style="width:540px;">控制生产者发送消息的大小，它可以指定单个消息的最大值，也可以指定单个请求里所有消息大小的总和。比如1MB，那么单个消息最大大小是1MB，同时如果消息大小是1KB，那么一次可以发送1000条消息。另外broker也有接受消息最大的限制，<a href="https://blog.csdn.net/qq_31617409/article/details/81836831" rel="nofollow">message.max.bytes</a>,(参考博主的broker配置文章)所以两边最好能够匹配。避免生产者发送消息被broker拒绝。</td>
		</tr><tr><td style="width:259px;">
			<p>receive.buffer.bytes</p>

			<p>send. buffer.bytes</p>
			</td>
			<td style="width:540px;">这两个参数分别指定了TCP socket 接收和发送数据包的缓冲区大小。如果它们被设为-1 ,<br />
			就使用操作系统的默认值。如果生产者或消费者与broker 处于不同的数据中心，那么可以<br />
			适当增大这些值，因为跨数据中心的网络一般都有比较高的延迟和比较低的带宽。</td>
		</tr><tr><td colspan="2">kafka可以保证一个分区内的消息是有序的，如果生产者按照一定的顺序发送消息，那么broker会按照这个顺序将他们写到分区中，消费者也会按照同样的顺序消费他们，<span style="color:#f33b45;"><strong>但是！如果设置了retries大于1，而设置了max.in.flight.requests.per.connection也是大于1的数，比如是2，那么。。当消息批次1发送之后，尚未收到服务器的响应，此时消息批次2也被发送，但是，消息批次1失败了，消息批次2成功了，那么此时由于retries设置了大于1的数，所以出发了重试机制，那么消息批次1开始进行重试发送，此时假设消息批次1发送成功了，那么这样的话，尽管消息发送的顺序是：消息批次1，消息批次2，但是最终服务端的顺序确实消息批次2，消息批次1。顺序被打乱了。。。所以如果对于顺序有着严格要求，最好将 </strong></span><em><u><strong>max.in.flight.requests.per.connection </strong></u></em><strong>设置为<span style="color:#f33b45;">1，将retries设置大于1的数。这样即使发生重试，也不会打乱消息的先后顺序。</span></strong></td>
		</tr></tbody></table><p> </p>          </div>
                  </div>
  </article>
</div>
</html>
